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(54) Architecture de systeme de traitement de I'information 



(57) L'invention conceme une architecture de sys- 
teme de traitement de ('information comprenant un en- 
semble de produits logiciels subdivise en domaines 
(21-23) comprenant chacun au moins un produit logi- 
ciel. Chaque domaine (21-23) contient des informations 
specifiques comprenant un identifiant du domaine 
(21-23), des attributs, et des donnees sur les produits 
logiciels le composant. Ces donnees permettent I'instal- 
lation et/ou la mise a jour des domaines (21 -23) en fonc- 
tion d'un jeu de regies. Les produits logiciels sont cons- 



titues de produits entierement integres aux domaines, 
obeissant a des regies d'installation et/ou de mise a jour 
standards communes au systeme, et de produits hete- 
rogenes, d'origine externe, dont le conditionnement et 
les regies d'installation et/ou de mise a jour restent spe- 
cifiques. Uncontrolede coherence portantsur la version 
peut etre effectue sur tout ou partie de ces produits ex- 
ternes. Le systeme (2) comprend au moins deux domai- 
nes specifiques pour le systeme d'exploitation (21 ) et le 
moniteur d'exploitation (23) du systeme (2). 
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Description 

La presente invention concerne une architecture de 
systeme de traitement de I' information. 

Elle concerne plus particulierement une architectu- 
re pour des systemes de grande puissance, du type dit 
"mainframe", selon la terminologie anglo-saxonne. 

De tels systemes, tres complexes, integrent de tres 
nombreux sous-systemes, tant materiels que logiciels 
qui cooperent entre eux. II n'est pas rare que des pro- 
duits logiciels constituants de ces systemes, compor- 
tent des centaines de milliers, voire des millions de li- 
gnes de code. 

Dans ce contexte, un des problemes les plus diffi- 
ciles a resoudre est d'obtenir la coherence et la compa- 
tibility entre les differents composants, notamment lors- 
qu'ils doivent etre mis a jour (passage a des versions 
plus recentes, ajout de modules ou de fonctions, etc.). 

En effet, outre la complexity intrinseque rappel6e, 
on doit egalement tenir compte du fait que les differents 
produits composant le systeme ont des provenances 
disparates, que ce soit en interne (meme si des regies 
de developpement communes sont en vigueur) ou en 
externe (produits disponibles sur le marche). 

Dans I'etat de la technique, il existe deux types prin- 
cipaux d'architectures. 

Une premiere architecture appartient au type dit 
"proprietaire". Sous ce vocable, on designe des syste- 
mes dont ('architecture est congue par le construct eur 
de materiel informatique. 

{.'architecture se caracterise essentiellement par 
une integration poussee et se presente sous la forme 
d'un systeme monolithique. La figure 1 annexee a la pre- 
sente description illustre schematiquement une telle ar- 
chitecture. 

Le systeme 1 comprend une plate-forme materielle 
1 0 cooperant avec un ensemble monolithique 1 1 de sys- 
temes logiciels. Ceux-ci peuvent comprendre un syste- 
me d'exploitation 110, ou "OS" selon la terminologie 
anglo-saxonne ("Operating System"), un systeme d'ad- 
ministration 111, qui supervise les fonctions systemes, 
et un systeme de production 112. Ce dernier peut com- 
prendre, par exemple, des gestionnaires de bases de 
donnees, 113, et des processus transactionnels, 114. 
La plate-forme materielle, 10, comprend les dispositifs 
habituels d'un systeme de traitement de donnees : unite 
centrale, m^moire centrale, m6moires de masse, etc., 
qu'il est inutile de detailler plus avant. 

Dans le systeme de la figure 1 , tous les composants 
de ('ensemble 11 sont pris en compte lors de Installa- 
tion initiale et lors des mises a jour ulterieures (change- 
ment de version du systeme 1 ). Dans ce type d'environ- 
nement, la coherence du systeme est obtenue par la 
validation globale des interfaces entre tous les compo- 
sants. Pour I'utilisateur, ces dispositions garantissent 
une grande robustesse du systeme independamment 
de ses evolutions. En outre, elles permettent un suivi 
simplifie des versions successives du systeme. Enfin, 



elles assurent une disponibilite maximale et une grande 
securite de fonctionnement, puisque les risques de dys- 
fonctionnement sont reduits au minimum. 

Cependant, il existe en contrepartie des contraintes 

s et des inconvenients serieux. 

Ceux-ci trouvent leur origine dans le fait que les sys- 
temes sont monolithiques. Quel que soit le composant 
a changer et/ou la fonction a ajouter, il est necessaire 
d e f a i r e evoluer tout le systeme. La mise a jour ne peut 

10 etre que globale. 

Pour illustrer de facon pratique cet inconvenient, on 
peut citer, a titre d'exemple, le cas d'un utilisateur qui ne 
des ire rait remplacer que le logiciel de g est ion de bases 
de donnees 113 ; ou le mettre a jour en faisant appel a 

is une version plus recente. Dans cette hypothese, il sera 
oblige d'implanter une version nouvelle complete du 
systeme. 

Cela presuppose d'ailleurs que cette version nou- 
velle, comprenant le logiciel de gestion de base de don- 
20 nees a remplacer ou a mettre a jour, soit disponible. 

Enfin, cela entraine une indisponibilit6 importante 
du systeme de traitement de donnees, couramment plu- 
sieurs jours pour de tres gros systemes. 

II s'ensuit que ce type d'architecture a relativement 
25 peu do souplesse et presente des possibilites d'evolu- 
tion limitees. 

Une seconde architecture appartient au type dit 
"ouvert". Sous ce vocable, on designe des systemes 
dont I'architecture n'est pas definie par un seul construc- 
30 teur. Ces systemes sont apparus, notamment, avec 
('emergence des systemes d'exploitation du type 
"UNIX" (marque deposee) ou similaires, par exemple 
"AIX" (marque deposee). 

II est clair que ce type d'architecture est tres attrac- 
ts tif, car il permet de faire appel a des logiciels heteroge- 
nes, c'est-a-dire d'origines diverses, coexistant sur une 
meme machine. 

Pour ce type d'architecture, I'installation et/ou la mi- 
se a jour d'un logiciel ne concernent que le produit lui- 
40 meme, et non le systeme dans sa globalite. 

Puisque des composants de base peuvent etre ins- 
talled ou mis a jour a tout moment, une architecture 
"ouverte" offre done une tres grande souplesse et des 
facilites devolution importantes, du moins en theorie. 
45 En effet, ce type d'architecture n'est pas non plus 
exempt d'inconvenients. En particulier, il n'oftre aucune 
garantie de bon fonctionnement avec les autres compo- 
sants logiciels : possibilites d'incompatibilit6 diverses, 
etc. 

so Or, malgre les inconvenients qui lui sont inherents, 
un systeme a architecture ouverte reste tres seduisant 
pour les utilisateurs. 

En effet, il permet de satisfaire, tout ou partie, des 
besoins des utilisateurs de systemes informatiques qui 

55 se font actuellement sentir, parmi lesquels : 

autonomie, e'est-^-dire la possibility de faire 6vo- 
luer un ou plusieurs produits du systeme, indepen- 



; 
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damment du reste du systeme ; 

parallelisme, c'est-a-dire la possibiiite de faire tour- 
ner plusieurs versions du meme produit 
simultanement ; 

compatibilite, c'est-a-dire pouvoir compter sur une 
garantie de compatibilite ascendante des produits 
et des interlaces entre produits ; 

mise a jour pendant I'exploitation courante du sys- 
teme, c'est-a-dire pouvoir changer de version d'un 
produit sans arret de I'exploitation ou , pour le moins, 
avec un arret minimum ; 

retour en arriere, c'est-a-dire la possibiiite de reve- 
nir a une version anterieure d'un produit en cas de 
p rob I erne, sans arret de I'exploitation ; 

maitrise des evolutions, c'est-a-dire la possibiiite de 
reste r matt re du processus devolution par la mise 
en oeuvre de procedures automatisees et 
simplifiees ; 

et rapidite des evolutions et de la maintenance, 
c'est-a-dire pouvoir compter sur un delai minimum 
entre une demande d'evolution ou de correction, et 
son installation effective sur site. 

L'invention se fixe pour but de pallier les inconve- 
nients des deux types d'architectures de I'art connu, tout 
en conservant les avantages de chacun. 

Elle vise par ailleurs a repondre pleinement aux be- 
soins des utilisateurs qui viennent d'etre rappeles. 

Pour ce faire, et selon une caracteristique principa- 
te, invention propose une architecture en domaines. 

Un domaine regroupe un ensemble de fonctionna- 
lites offertes par des composants logiciels du systeme. 
II a des caracteristiques propres et evolue de facon in- 
dependante. Le systeme est alors compose d'un en- 
semble de domaines ayant un minimum d'interdepen- 
dances, ce qui garantit la coherence globale. 

En d'autres termes, la souplesse d'installation et la 
mise a jour sont introduites a un niveau macroscopique 
qui reste maltrisable, c'est-a-dire le domaine au sein du- 
quel la coherence reste assuree. 

Chaque domaine, quel qu'il soit, est D vu u de facon 
identique par I'utilisateur, grace notamment a des attri- 
buts qui iui sont affectes et un descripteur. 

L'invention a done pour objet une architecture de 
systeme de traitement de ('information, ledit systeme 
comprenant une plate-forme materielle cooperant avec 
un ensemble de produits logiciels, caracterisee en ce 
que ledit ensemble est subdivise en sous-ensembles 
dits domaines comprenant chacun au moins un desdits 
produits logiciels, en ce que chaque domaine contient 
un sous-ensemble dit descripteur donnant acces a des 
informations specifiques determinees, lesdites informa- 
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tions comprenant au moins un identifiant du domaine et 
des donnees decrivant les produits logiciels le compo- 
sant, et en ce qu'il est prevu des moyens permettant 
['installation et/ou la mise a jour desdits domaines a par- 
s tir de regies predeterminees et desdites informations 
specifiques determinees. 

On constate que ('architecture selon l'invention pre- 
sente de nombreux avantages, parmi lesquels : 

10 - Souplesse de mise a jour : il n'y a jamais necessite 

de proceder a une mise a jour totate du systeme, 
celle-ci pouvant etre effectuee domaine par domai- 
ne. 

is - Indisponibilrte reduite de la machine : la mise a jour 
pouvant etre effectuee en plusieurs phases, celles 
relatives aux quelques domaines necessitant un ar- 
ret de production peuvent avoir lieu a des moments 
choisis. Dans une variante avantageuse de IMnven- 

20 tion, ia plupart des domaines peuvent etre mis a jou r 
sur une copie secondaire pendant que la production 
continue sur une copie primaire. Seul le bascule- 
ment final peut entralner, pour des domaines spe- 
cifiques, I'arret de la production. 

25 

Securite des changements de version : certains do- 
maines pouvant fonctionner en double occurrence, 
ils permettent des phases de tests et des retours en 
arriere en cas de probleme. 

30 

Reduction des temps de mise a jour : les mises a 
jour s'effectuant au niveau du domaine, leur reali- 
sation peut etre etudiee et planifiee au mieux, en 
fonction des contraintes d'exploitation. 

35 

Souplesse du choix des configurations ir^stallees : 
I'utilisateur a la possibiiite de n'installer que les do- 
maines qui Iui sont necessaires et maltriser com- 
pletement revolution des versions de chaque do- 
40 maine, dans la seule limite des contraintes impo- 
sees par les dependances eventuelles et les con- 
ditions de support et de maintenance. 

En resume, I'architecture selon l'invention permet 
45 de cumuler les avantages des architectures de type 
"proprietaire" et de type -ouvert" : robustesse, disponi- 
bilite, securite, souplesse et evolutivite. 

L'invention sera mieux comprise et d'autres carac- 
teristiques et avantages apparaltront a la lecture de la 
so description qui suit en reference aux figures annexees, 
parmi lesquelles : 

la figure 1 illustre schematiquement une architectu- 
re de type "proprietaire" selon I'art connu ; 

55 

la figure 2 illustre schematiquement un exemple de 
realisation d'une architecture selon l'invention ; 
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la figure 3 illustre schematiquement la structure 
d'un domaine, element constitute de base de ('ar- 
chitecture de la figure 2 ; 

les figures 4a a 4d illustrent difterents types de 
domaines ; 

les figures 5a et 5b illustrent un exemple d'organi- 
sation hierarchique des domaines ; 

et la figure 6 illustre un domaine particulier et ses 
relations avec les autres domaines du systeme. 

On va maintenant decrire de facon detaillee I'archi- 
tecture d'un systeme de traitement de donnees selon 
I'invention par reference a la figure 2. 

Le systeme 2 comprend, comme precedemment 
une plate-forme materielle 20. Cependant, selon une 
caracteristique importante de I'invention, I'ensemble 
des logiciels et progiciels est scinde en domaines, 21 a 
23. De facon plus particuliere, il existe un ensemble de 
domaines, D-,, D 2 , .... D y , ...,D n , regroupes sous la refe- 
rence generate 22, et deux domaines specif iques, 21 et 
23. Ces deux derniers domaines sont, respectivement, 
le domaine 21 fournissant le systeme d'exploitation (ou 
"OS 11 ) et les logiciels de base associes du systeme, et 
le domaine 23 fournissant le moniteur d'exploitation du 
systeme 2. Le systeme 2 comprend au minimum ces 
deux domaines, 21 et 23, en sus de la plate-forme ma- 
terielle 20. C'est la version du domaine 23 : moniteur 
d'exploitation du systeme : qui identifie completement 
I'ensemble du systeme 2 et de ses composants de base, 
c'est-a-dire, comme il le sera explicite ci-apres, les dif- 
ferent© domaines et les fonctionnalites qu'ils off rent. 

Les indices j et n reperant les domaines sont pure- 
ment arbitrages, j etant un indice intermediate et n le 
nombre maximal de domaines (non compris tes domai- 
nes specifiques 21 et 23), du moins dans un etat de con- 
figuration donne du systeme. 

Les autres domaines, 22, sont optionnels et sont 
selectionnes par I'utilisateur en fonction de ses besoins 
precis et de I'application consideree. Dans ce qui suit, 
on appellera ces domaines "domaines banalises", en ce 
sens qu'ils sont "vus" de facon semblable par le syste- 
me, comme il le sera explicite ci-apres, meme si leur 
contenu est different. Le systeme 2 est done entiere- 
ment modulaire au niveau des domaines. 

Pour fixer les idees : les domaines suivants peuvent 
etre implemented dans le systeme : fonctions d'admi- 
nistration du systeme, fonctions de traitement par lots, 
fonctions de gestion de bases de donnees, fonction de 
securite, fonctions de gestion des processus transac- 
tionnels et fonctions d' interoperability. 

Un systeme determine 2, repondant aux besoins de 
rutilisateur, est installe dans un etat donne. En d'autres 
termes, la configuration et les versions des domaines 
sont precisement d6finies. 

Cette installation peut etre obtenue de deux 



facons : 

II s'agit tout d'abord de I'installation initiale propre- 
ment dite, que Ton peut appeler "cles en mains", 
5 c'est-a-dire d'une pre-configuration realisee en usi- 
ne. 

II peut s'agir aussi d'une mise a jour incremental 
de la machine sur site d'exploitation. Les mises a 
10 jour concernent alors un ou plusieurs domaines, se- 
lon les besoins. Mais il n'est jamais necessaire, con- 
trairement aux systemes de type "proprietaire" de 
I'art connu, de modifier tout ie systeme 2. 

is II existe en realite deux types principaux de mise a 
jour : 

La mise a jour proprement dite (ou "update" selon 
la terrninologie anglo-saxonne) : un domaine don- 
20 ne, Dy, ayant fait I'objet d'une installation initiale, il 
s'agit d'en installer une version plus recente pour y 
incorporer, soit des nouvelles fonctionnalites, sort 
des corrections. Cette operation entrain e notam- 
ment le changement de la version du domaine. 

25 

Ajout (ou "add-on" selon la terrninologie anglo- 
saxonne) : il s'agit de I'ajout pur et simple d'un do- 
maine particulier, par exemple D^ qui n'avait pas 
ete installe initialement. 

30 

II doit etre clair egalement que un ou plusieurs do- 
maines peuvent etre supprimes. 

Tous les domaines, 21 a 23, cooperent avec la pla- 
te-forme materielle 20, directement ou via le domaine 
35 de base ou systeme d'exploitation 21. De meme, tous 
ies domaines "banalises" 22 cooperent avec les domai- 
nes specifiques, 21 et 23. Des liens verticaux (sur la fi- 
gure 2) illustrent ce mode de fonctionnement. 

Selon un autre aspect de I'inventbn, il est avanta- 
40 geux que les domaines 22 presentent la plus grande in- 
dependance les uns vis-a-vis des autres. En d'autres 
termes, il est important que les interactions entre ces 
domaines soient minimisees. Generalement, il existe 
cependant des relations entre certains des domaines D 1 
45 a Da Ces relations ont ete figurees par des liens hort- 
zontaux (sur la figure 2). 

Bien que le nombre de domaines ne soit pas, a prio- 
ri, limite dans la pratique, le nombre raisonnable de do- 
maines est pr6ferentiellement inferieur a dix et, en tout 
so cas, devrait se situer dans la gamme de dix a vingt au 
maximum. 

Dans le cas contraire, la complexite augmente de 
fa?on tres importante : fonction cn x(x-1 )/2, avec x nom- 
bre total de domaines. Les avantages apportes par I'ar- 
55 chitecture selon I'invention s'en trouvent alors large- 
ment amoindris. 

On va maintenant decrire de facon plus d6taillee 
I'unite 6lementaire queconstitue un domaine, Dy, par re- 



25 



30 



35 



40 



4 



7 

ference a la figure 3. Cette figure 3 iltustre schematique- 
ment la structure d'un domaine, par exemple le domaine 
Dy d'indice arbitraire / 

On peut definir un domaine D y comme etant une uni- 
te independante d' integration, d'installation et de mise 
a jour. Elle comprend un ou plusieurs logiciels ou progi- 
ciels de provenances diverses : interne ou externe, que 
Ton appellera produits. Par "interne", on entend des ap- 
plications de type "proprietaire". Par "externe", on en- 
tend des applications disponibles sur le marche. 

De lacon plus precise, un domaine comprend deux 
parties principaies. 

Une premiere partie 4 est constitute des differents 
produits offrant des fonctionnalites propres a un domai- 
ne, reperees 40 a 42. A titre d'exemple, un domaine de 
traitement par lot offrira au moins les fonctions suivan- 
tes: gestions des impressions et des sauvegardes. 

La seconde partie 3 constitue une interface particu- 
liere du domaine Dy, que I'on peut appeler "descripteur" 
qui donne acces a des donnees decrivant le domaine 
et ses proprietes. 

Les fonctionnalites fournies par les domaines Dy 
sont supportees par des produits qui se caracterisent, 
entre autres, par la maniere dont ils sont integres dans 
le systeme 2, par la facon dont ils s'installent et s'exe- 
cutent et par les autres produits (c'est-a-dire les autres 
domaines) dont ils dependent eventuellement. 

Un domaine Dyne peut regrouper que des produits 
ayant des caracteristiques identiques, ou pour le moins 
compatibles Celles-ci lui sont associees sous forme de 
trois attributs : le niveau d' insert ion, letyped'occurrence 
et les dependances. 

C'est done les domaines qui assurent et garantis- 
sent les differentes caracteristiques avantageuses re- 
cherchees pour le systeme, dans sa globalite, en raison 
de I'homogeneite des produits les composant. 

La partie 3 ou descripteur doit done donner acces 
a des informations caracterisant un domaine particulier 
D y , notamment a un identifiant concernant son nom et 
sa version, et a une liste de ses composants. En outre, 
un domaine Dy est caracterise par un certain nombre 
d'attributs, comme il a ete indique, qui vont etre detailles 
ci-apres. Toutes ces informations sont necessaires pour 
pouvoir realiser les operations de base 
susmentionnees : installation et mise a jour des domai- 
nes. Elles decrivent aussi le mode de fonctionnement 
des produits composant le domaine. 

Dans un mode de realisation prefere de ('invention, 
les attributs sont au nombre de trois, a savoir le niveau 
d'insertion, le type d'occurrence et les dependances. 

Un niveau d'insertion est caracterise par la maniere 
dont les produits constituant le domaine y sont integres, 
c'est-a-dire quelles caracteristiques fonctionnelles sont 
controlees, notamment lors des operations d'installation 
et, surtout, de mise a jour. 

Pour fixer les idees, et dans un mode de realisation 
pratique de I'invention, on a defini quatre niveaux d'in- 
sertion. 
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Ces niveaux sont illustres schematiquement par les 
figures 4a a 4d, representant quatre domaines arbitrat- 
es, de niveaux d'insertion respectifs, N 0 a N 3 . 

Tout d'abord, il est utile de rappeler que les produits 

5 constituant les domaines peuvent etre des produits de- 
veloppes par le constructeur lui-meme, que Ton a appe- 
le "proprietaire", c'est-a-dire d'origine interne, ou des 
produits externes. Ces derniers peuvent avoir ete com- 
pletes pour etre mieux adaptes au systeme 2 (figure 2). 

io On parle alors de valeur ajoutee. 

Ceci etant rappele, le "niveau 0", N 0 , illustre par la 
figure 4a, ne comprend que des produits externes, par 
exemple reperes P 0 /et P 0 y, sans aucune valeur ajoutee. 
Vu du systeme, un produit, Pq/OU P 0 y, d'un domaine de 

15 niveau 0 est identique a un produit qui serait vu dans un 
systeme ouvert selon I'art connu. Aucun controle n'est 
exerce sur ces produits lors de leur installation et/ou leur 
mise a jour. 

En realite, un domaine de niveau 0 ne constitue 
20 qu'un pseudo-domaine. On peut d'ailieurs considerer 
que les produits, par exemple Po,eX P 0y , constituent un 
ensemble de produits installes dans le systeme, mais 
qui ne presentent pas, a proprement parler, les carac- 
teristiques de ('invention. Ce niveau autorise cependant 
25 une souplesse supplemental offerte a I'utilisateur du 
systeme. 

Au "niveau 1", N lf illustre par la figure 3b, les pro- 
duits, par exemple P-j/et P 1; , ne sont pas, a proprement 
parler, integres dans le systeme, mais il peut exister une 
30 Valeur ajoutee" a ces produits et/ou un controle de la 
version du produit installe, du moins pour certains des 
produits. 

Sur la figure 4b (et les suivantes). on a represente 
symboliquement en hachure les parties du domaine 

3S comportant des composants reellement integres, par 
exemple des routines de controle CTL1j du produit P,y, 
le produit P-, ,-, n'etant pas controle du tout (comme dans 
le cas du niveau 0). 

Les produits, Pi, et P-,y, conservent leur condition- 

40 nement d'origine ("packaging") et le support prevu par 
leur concepteur. La mise a jour de ces produits est faite 
independamment de celle du domaine et peut etre con- 
trolee ou non, comme il a ete indique ci-dessus, par 
comparaison avec des donnees ou a I'aide de regies 

45 preetablies. 

A titre d'exemple de realisation pratique, le domaine 
de base 21 (figure 2) lournit le systeme d'exploitation, 
par exemple de type "AIX" (marque enregistree). Le do- 
maine 21 est alors au niveau d'insertion 1. 

50 La figure 4c illustre un domaine de "niveau 2", N^. 
A ce niveau, tous les produits, par exemple P 2/ et P 2 y, 
sont sous le controle de routines integrees, Ct^/et Ct1 2 y. 
A cette exception pres, le niveau 2, N 2 , est tout a fait- 
simiiaire au niveau 1, N v II est done inutile d'en redecrire 

ss les caracteristiques. 

La figure 4d illustre un domaine de niveau d'inser- 
tion 3, N 3 , ou niveau superieur. Ce niveau repond plei- 
nement aux caracteristiques de I'invention. En effet, 
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tous les composants, par exemple P 3i e\ P 3 p sont entie- 
rement integres dans le domaine, ce qui est represents 
symboliquement, sur la figure 4d, par un double trait en- 
tourant ces produits. 

S'il s'agit de produits d'origine externe, leur condi- 
tionnement est entierement redefini et ces produits 
s'installent et se mettent a jour selon une procedure 
standard propre au systeme, procedure qui ne neces- 
site aucune expertise sur le produit installe. II ne s'agit 
plus alors que de controles simples, tels que le seul con- 
trole de la version du produit a installer ou a mettre a 
jour. 

Un domaine, a ce niveau d'insertion, peut done ga- 
rantir pleinement toutes les caracteristiques avantageu- 
ses recherchees dans le cadre de I'invention : robustes- 
se, disponibilite, securite, souplesse et evolutivite. 

Un deuxieme attribut associe a un domaine parti- 
culier Dj (figure 3) est le type d'occurrence. II caracterise 
le nombre d'instances que Ton peut f aire coexister et/ou 
executer simultanement sur un meme noeud, etant en- 
tendu qu'un noeud est un element materiel d'un syste- 
me distribue. 

De facon avantageuse, tous les produits compo- 
sant un meme domaine, D^, doivent presenter le meme 
type d'occurrence. Dans le cas contraire, on retient le 
type d'occurrence le plus faible. 

On peut definir trois types d'occurrence principaux : 

Un premier type d'occurrence, appele ci-apres 
"SISR" (ou "Single Intall & Single Run"), permet une 
seule occurrence du domaine conceme et, a fortio- 
ri, une seule execution. Le remplacementd'une ver- 
sion d'un domaine ne peut etre realise qu'en rem- 
plagant la precedente. 

Un deuxieme type d'occurrence, appele ci-apres 
"MISR" (ou "Multiple Intall & Single Run"), permet 
une installation multiple du domaine concerne sur 
un meme noeud, mais toujours une seule execu- 
tion. Chaque occurrence correspond a une version 
differente du domaine, mais la meme version d'un 
produit peut exister en plusieurs occurrences dans 
des versions differentes d'un domaine. 

Un troisieme type d'occurrence, appele ci-apres 
"Ml MR" (ou "Multiple Intall & Multiple Run"), permet 
une installation multiple du domaine concerne sur 
un meme noeud et ainsi qu'une execution multiple. 

Le type d'occurrence associe a un domaine a une 
grande importance, car il conditionne directement la dis- 
ponibilite du systeme pendant les mises a jour. 

Avec une occurrence de type "SISR", il n'existe 
qu'une instance du domaine concerne et on ne peut 
executer que cette nouvelle instance et il n'est pas pos- 
sible de revenir en arriere, du moins sans supprimer 
I'instance en cours. En outre, la mise a jour d'un domai- 
ne peut necessiter I'arret complet du systeme. 



Avec une occurrence du type "MISR", plusieurs ins- 
tances correspondant a des evolutions du domaine peu- 
vent coexister, bien qu'une seule soit executable a un 
instant donne. On peut cependant choisir I'instance qui 

5 sera executee. 1 1 est done possible de revenir en arriere, 
car il est possible de choisir I'instance a executer. En 
d'autres termes, il est possible d'arreter I'instance nou- 
velle, sans refaire une mise a jour. La suppression de 
I'ancienne instance peut etre completement desynchro- 

10 nisee de ('installation de la nouvelle instance. Sexploi- 
tation peut continuer pendant le temps de la mise a jour. 
Elle ne doit etre interrompue, du moins en ce qui con- 
cerne les produits du domaine conceme, qu'au moment 
du basculement vers la nouvelle version. 

is Avec uneoccurrence du type "MIMR", plusieurs ins- 
tances pouvant coexister et toutes etant executables si- 
multanement; il devient possible de mettre en service 
une nouvelle version de facon progressive, par exemple 
en maintenant I' exploitation sur I'ancienne version et en 

20 executant des tests sur la nouvelle. On obtient alors la 
maTtrise complete du basculement vers la nouvelle ver- 
sion. En outre, sauf contraintes particulieres, ce type 
d'occurrence autorise 1'installation d'une nouvelle ver- 
sion sans interruption de ('exploitation du produit con- 

2S cerne. 

Ce type d'occurrence off re done une souplesse 
maximale, tout en assurant les caracteristiques avanta- 
geuses rappelees. 

On doit noter enfin que, au prix d'un reconditionne- 
30 ment, un produit d'origine externe offrant une occurren- 
ce initiale du type "SISR", par exemple, peut offrir une 
occurrence superieure de type "MISR", voire "MIMR\ 
ce qui le rend plus attractif. 

Un troisieme attribut associe a un domaine particu- 

35 Ner Dj (figure 3) concerne les dependances. Les depen- 
dances indiquent le ou les autres domaines, D 1 a Da 
du systeme 2 (figure 2) dont la presence est necessaire 
au bon fonctionnement des produits du domaine Dj con- 
cerne. Les dependances d'un domaine Dj sont consti- 

40 tuees par ('ensemble des dependances identifies au 
niveau de chaque produit constituant ce domaine. 

Pour obtenir les caracteristiques avantageuses de 
('architecture de I'invention, il est avantageux de ne re- 
grouper, dans un meme domaine, que des produits 

45 ayant les memes dependances. Les domaines drts de 
base. (figure 2 : 21) et de moniteur d'exploitation (figure 
2 : 23) constituant le coeur du systeme, tous les autres 
domaines, D n a D n , onl une dependance vis-a-vis de 
ces deux domaines specifiques. Enfin, lorsqu'un domai- 

so ne a une occurrence multiple, dutype "MISR"ou MIMR", 
il ne doit jamais exister de dependances entre ses dif- 
ferentes occurrences. 

On va maintenant decrire de facon detaillee un 
exemple d'organisation pratique d'un domaine Dy. 

55 Dans cet exemple pratique, le domaine est organi- 

se selon une hierarchie d'objets. Cette structure ne s'ap- 
plique, strictosensu, qu'aux domaines dont I'attribut in- 
sertion est de niveau 3 (voir figure 4d) ou, pour les do- 
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maines de niveaux d'insertion 1 et 2 (figures 4b et 4c), 
aux produits entierement integres (zones hachurees de 
ces figures). 

On va considerer ci-apres, par reference aux figu- 
res 5a et 5b, pour des raisons de simplification, un do- 
maine Dy ne contenant qu'un seul produit P /: etant ad- 
mis que ces dispositions s'apptiquent tout aussi bien a 
des domaines comprenant plusieurs produits. tl est en 
effet clair que la structure de base d'un domaine est le 
produit, comme le montre plus particulierement la figure 
5b, un domaine comprenant un ou plusieurs produits. 

On peut cependant distinguer une structure hierar- 
chique a quatre niveaux, dans un mode de realisation 
avantageux de ('invention. 

Le premier niveau est le produit P,- proprement dit. 
C'est un ensemble homogene oflrant une fonctionnalite 
don nee. Le produit est constitue d'un ensemble de mo- 
dules Mfl a M s (trois dans I'exemple decrit sur la figure 
5a) ou "packages", qui constituent le deuxieme niveau 
hierarchique. 

Le deuxieme niveau regroupe done les modules M rt 
a M Q . Un module M rt a est un sous-ensemble fonc- 
tionnel homogene d'un produit P,-. II est constitue d'un 
ensemble de jeux de fichiers ou "filesets" FS n , FS S et 
FS ei et FS^ (dans I'exemple decrit sur la figure 5a). 

Ces deux niveaux constituent un premier niveau de 
visibility externe, NVe, e'est-a-dire "visible" par I'utilisa- 
teur pour une mise a jour du domaine Dy et/ou son ins- 
tallation iniliale. 

1 1 est ainsi possible d'installer tout ou partie des pro- 
duits d'un domaine Dj, ainsi que tout ou partie des mo- 
dules les composant, en tenant compte naturellement 
de contraintes de coherence liees a ces produits. 

Le troisieme niveau regroupe les jeux de fichiers 
FS rt , FS C et FS 01 et FS^. Un jeu de fichiers est un 
ensemble de fichiers contribuant a la realisation de tout 
ou partie des fonctionnalites offertes par un module. Un 
module, par exemple les modules M rt et M e , peut ne 
comprendre qu'un seul jeu de fichiers, FS n et FS e , res- 
pectivement. Au contraire, un module peut comprendre 
deux jeux de fichiers ou plus. C'est ie cas du module M 0 
qui comprend deux jeux de fichiers, FS^-, et FS Q2 - 

Le quatrieme niveau est constitue par les fichiers 
eux-memes, F rt1 , F, 12 , F S1 , F^. F/3i . F/321 et ? B2 2- Cha " 
que jeu de fichiers peut comprendre un ou plusieurs fi- 
chiers. 

Les troisieme et quatrieme niveaux constituent un 
niveau de visibility interne NVi, non visible par I'utilisa- 
teur en utilisation normale. Cependant, les mises a jour 
concernent ce niveau. 

La structure de base d'un produit etant hierarchi- 
que, les regies suivantes doivent etre suivies : 

un module appartient a un produit et a un seul et 
contient au moins un jeu de fichiers ; 

un jeu de fichiers appartient a un module et a un 
seul et contient au moins un fichier ; 



un fichier appartient a un jeu de fichiers et a un seul. 

Un domaine Dy est un ensemble de produits et de 
modules. II comprend toujours, et au minimum, un mo- 

s dule et un jeu de fichiers specifiques decrivant le domai- 
ne Dy. Ce jeu de fichiers specifiques comprend, au 
moins, un fichier egalement specifique contenant la lis- 
te, e'est-a-dire le nom et le numero de version, de tous 
les autres jeux de fichiers du domaine Dy. Outre son role 

10 de conteneur ce fichier particulier sert a assurer la co- 
herence du domaine Dy. En effet, selon une caracteris- 
tique de I'inventbn, tous les autres jeux de fichiers du 
domaine Dysont declares dependants du jeu de fichiers 
specifiques. L' installation ou la mise a jour d'un jeu de 

is fichiers quelconque, appartenant au domaine Dy, n'est 
possible que si la version du domaine le permet, du 
moins en ce qui concerne les produits controles ou in- 
tegres (niveaux d'insertion 1 a 3). 

L'usage des jeux de fichiers d iff ere d'ailleurs selon 

20 ie niveau d'insertion considered 

Dans un domaine de niveau d'insertion 3, les jeux 
de fichiers sont constitues de programmes executables 
du produit. 

Dans un domaine de niveau d'insertion 1 ou 2, les 

25 jeux de fichiers ne contiennent pas, a I'exception des 
"valours ajoutees", les produits eux-memes, produits 
qui sont exterieurs au domaine, car d'origine externe. 
lis servent seulement a les decrire et a effectuer des 
controles de version lors de I'installation et/ou de la mise 

30 a jour. De facon generate, pour I'installation d'un produit 
d'origine externe, il est necessaire que le jeu de fichiers 
du domaine contienne des utilitaires sous la forme de 
"scripts" qui s'executent lors de I'installation effective et 
effectuent des verifications sur le produit reel. Ces 

35 scripts peuvent egalement declencher I'installation pro- 
prement dite du produit ou sa mise a jour.. 

Dans un mode de realisation particulier de I'inven- 
tion, illustre schematiquement par la figure 6, le systeme 
2 peut comprendre un troisieme domaine specifique, 

40 24, que Ton peut appeler domaine de service ou domai- 
ne "outils". 

Ce domaine comprend, notamment, des produits 
logiciels ou des utilitaires, egalement specifiques, per- 
mettant I'installation et/ou la mise a jour de tout ou partie 

45 des domaines, D A a D n , et dans chaque domaine, de 
tout ou partie des produits : qu'ils soient d'origine interne, 
e'est-a-dire a priori entierement integres aux domaines, 
ou externe, ces produits externes etant controles ou 
non, selon le niveau d'insertion associe au domaine. 

50 Naturellement, les outils, ou "moteurs", d'installation et 
de mise a jour presents dans ce domaine sont en inte- 
raction avec les domaines, D-, a D n , ainsi qu'avec le do- 
maine de base 21 , et le domaine moniteur Sexploitation 
23, et plus particulierement avec leurs ensembles des- 

55 cripteurs 3. Les installations s'effectuent selon des re- 
gies enregistrees dans le domaine 24 et/ou les ensem- 
bles descripteurs 3. 

Si on se reporte de nouveau a la figure 3, ce qui a 
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ete appele descripteur 3 donne acces a, au moins, un 
enregistrement 30, contenant te nom et la version du 
domaine Dj, a un enregistrement 31, decrivant les attri- 
buts associes a ce domaine et a un enregistrement 32, 
de description du content! du domaine et a un jeu de 
regies d' installation et de mise a jour du domaine et des 
produits le composant. Comme il a ete decrit en regard 
de la figure 5a, chaque domaine Dycomporte un jeu de 
fichiers specif ique contenant la liste des autres jeux de 
fichiers, c'est-a-dire au moins leurs noms et leurs nume* 
ros de version. On peut egalement completer ces infor- 
mations par des scripts et des regies d'installation et de 
mise a jour des produits externes au domaine. 

Bien que les informations rappelees ci-dessus puis- 
sent etre reparties a I'interieur d'un domaine donne, ce- 
lui-ci est "vu" de I'exterieurde facon identique, via ('en- 
semble descripteur 3 qui constitue une interface stan- 
dard pour tous les domaines, meme si le contenu de 
('information accedee differe d'un domaine a I'autre. 

De la description qui precede, on peut resumer I'or- 
ganisation des domaines et les principales regies d'uti- 
lisation de ceux-ci comme suit : 

chaque domaine est constitue d'un ensemble de 
jeux de fichiers, qui peuvent eux-memes etre re- 
groupes en modules et produits ; 

chaque domaine contient un jeu de fichiers specifi- 
ques qui determine son nom et sa version ; 

tous les domaines sont composes de jeux de fi- 
chiers disjoints ou, en d'autres termes, deux domai- 
nes distincts quelconques ne contiennent que des 
jeux de fichiers differents ; 

toute evolution d'un jeu de fichiers d'un domaine, 
d'une version de ce domaine a la suivante, doit res- 
pecter la regie dite de "compatibilite ascendante" : 
un jeu de fichiers de version m+1 , avec m arbitraire, 
en rempiacement de la version m, n'entraTne aucu- 
ne regression dans aucun des autres jeux de fi- 
chiers qui n'ont pas evolue ; 

et les dependances fonctionnelles sont definies au 
niveau des jeux de fichiers, mais elles sont rendues 
visibles de facon globale au niveau des domaines 
(attribut de dependances). 

A la lecture de ce qui precede, on constate aise- 
ment que ('invention atteint bien les buts qu'elle s'est 
fixes. 

Elle permet de conserves a la fois, Pessentiel des 
avantages de ['architecture des systemes dits "ouverts" 
et les avantages de ('architecture des systemes dits 
n propri6taires B , c'est-a-dire robustesse, disponibilite, 
securite, souplesse et evolutivite, sans en presenter les 
inconvenients. 

Elle s'accommode meme de ('installation et de la 
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mise a jour de produits d'origine extern e selon des pro- 
cedures qui leursont propres, avec un minimum de con- 
trole (version), voire sans controle du tout. Naturelle- 
ment, dans ce dernier cas, et pour ce seuls produits, on 

s se retrouve dans une configuration apparentee a celle 
presentee par un systeme "ouvert". Cette option permet 
d'obtenir une plus grande souplesse, toutefois en n'ob- 
tenant pas tous les avantages associes aux systemes 
"proprietaires". Cependant, les produits concemes, s'ils 

to existent, du fait de ('architecture en domaines propres a 
('invention, peuvent etre bien repertories et les risques 
d'apparition de problemes egalement bien delimites. II 
est enfin utile de rappeler que pour les produits d'origine 
externe, meme sans "valour ajoutee", et qui font I'objet 

is d'un controle de version, ce controle limite les risques 
precites. 

II doit etre clair cependant que I'invention n'est pas 
limitee aux seuls exemples de realisations explicitement 
decrits, notamment en relation avec les figures 2 a 6. 
20 Notamment, le nombre de domaines composant un sys- 
teme et/ou leur composition sont entierement depen- 
dants de ('application precise du systeme de traitement 
de donnees, ainsi que des besoins propres de Putilisa- 
teur. 

25 

Revendications 

1 . Architecture de systeme de traitement de ('informa- 
tion, ledit systeme comprenant une plate-forme ma- 
terielle (20) cooperant avec un ensemble de pro- 
duits logiciels, caracterisee en ce que ledit ensem- 
ble est subdivise en sous-ensembles dits domaines 
(21-24) comprenant chacun au moins un desdits 
produits logiciels (40-42), en ce que chaque domai- 
ne (21-24) contient un sous-ensemble dit descrip- 
teur (3) donnant acces a des informations specifi- 
ques determinees (30-32), lesdites informations 
comprenant au moins un identifiant (30) du domai- 
ne et des donnees (32) decrivant les produits logi- 
ciels le composant, et en ce qu'il est prevu des 
moyens permettant ('installation et/ou la mise a jour 
desdits domaines (21-24) a partir de regies prede- 
termines et desdites intormations specitiques de- 
terminees (30-32). 
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2. Architecture selon la revendicatton 1, caracterisee 
en ce que ledit identifiant (30) comprend au moins 
des informations de nom et de version de domaine. 

so 

3. Architecture selon la revendication 1, caracterisee 
en ce que lesdits produits logiciels appartiennent a 
deux categories, une premiere categorie represen- 
tant des produits logiciels, dits entierement integres 

55 auxdits domaines (21 -24), et obeissant a des regies 
d'installation et de mise a jour standardises, com- 
munes au systeme (2), et une deuxieme categorie 
representant des produits heterogenes, dits exter- 
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nes. conservant des regies specifiques d'installa- 
tion et de mise a jour 

4. Architecture selon la revendication 1 , caracterisee 
en ce que lesdites informations specifiques deter- 
minees comprennent en outre une serie d'attributs 
(31) associes auxdits domaines (21-24), decrivant 
des caracteristiques fonctionnelles specifiques as- 
sociees a ceux-ci. 

5. Architecture selon les revendications 3 et 4, carac- 
terisee en ce qu'un premier attribut est dit "niveau 
d'insertion'' et represente, selon une echelle prede- 
terminee, le niveau d'integration et de controle des- 
dits produits logiciels (P 0/ a P 3 y) constituant un do- 
maine determine (Dy). 

6. Architecture selon la revendication 5, caracterisee 
en ce que ladite echelle de niveaux d'insertion com- 
prend un niveau superieur (N 3 ) pour lequel tous les- 
dits produits logiciels sontdes produits logiciels (P 3/ 
a P 3 y) dits entierement integres obeissant auxdites 
regies d' installation et de mise a jour standardisees 
communes au systeme (2). 

7. Architecture selon la revendication 5, caracterisee 
en ce que ladite echelle de niveaux d'insertion com- 
prend des niveaux intermediates (N 0 -N 2 ) pour les- 
quels tout ou partie desdits produits logiciels (P 0 ,a 
P 2j ) sont des produits dits externes, en ce qu'au 
moins une partie de ces produits logiciels externes 
( p i/ p 2r p 2/) sont associes a une information dite 
de version, et en ce qu'il est prevu des moyens de 
comparaison avec lesdites informations specifi- 
ques pour effectuer un controle de coherence lors 
de I'installation de ces produits logiciels dans un do- 
maine determine (Dy) et/ou leur mise a jour. 

8. Architecture selon les revendications 3 et 4, carac- 
terisee en ce qu'un deuxieme attribut est dit "type 
d'occurrence" et represente la combinaison du 
nombre d'instances d'un domaine determine (Dy) 
qui peuvent etre installees et coexister sur ledit sys- 
teme (2), avec la possibilite ou non d'executer si- 
multanement ces instances. 

9. Architecture selon la revendication 8, caracterisee 
en ce que les types d'occurrence sont au nombre 
de trois : un premier off rant la possibilite d'une seute 
installation dudit domaine determine (Dy) dans le 
systeme (2) et d'une seule execution, un deuxieme 
offrant la possibilite d'une installation multiple et 
d'une seule execution, et un troisieme offrant la pos- 
sibilite d'une installation multiple et d'une execution 
multiple. 

10. Architecture selon les revendications 3 et 4, carac- 
terisee en ce qu'un troisieme attribut est dit "depen- 



dences" et pointe au moins un autre domaine dont 
la presence dans ledit systeme (2) est obligatoire 
pour le fonctionnement de tout ou partie desdits 
produits logiciels d'un domaine determine (Dy). 

5 

11. Architecture selon la revendication 1, caracterisee 
en ce que lesdites donnees sur les produits logiciels 
composant un domaine determine (Dy) compren- 
nent une liste decrivant le contenu de ce domaine 

io et un jeu de regies d' installation et de mise a jour 
du domaine et desdits produits logiciels le compo- 
sant. 

12. Architecture selon I'une quelconque des revendica- 
is tions 1 a 11, caracterisee en ce que ledit systeme 

(2) comprend au moins un premier domaine speci- 
fique (21), dit de base, tournissant un logiciel de 
systeme d'exploitation. 

20 13. Architecture selon la revendication 12, caracterisee 
en ce que ledit systeme (2) comprend au moins un 
deuxieme domaine specifique (23) fournissant un 
moniteur d'exploitation du systeme. 

2S 14. Architecture selon la revendication 1 3, caracterisee 
en ce que ledit systeme (2) comprend en outre un 
troisieme domaine specifique (24), dit de service, 
comprenant au moins des outils logiciels permet- 
tant I'installation et/ou la mise a jour detout ou partie 

30 desdits domaines (21) et des produits logiciels les 
composant. 

15. Architecture selon I'une quelconque des revendica- 
tions precedentes, caracterisee en ce que lesdits 

35 domaines (Dy) p resent ent une structure hierarchi- 
que a quatre niveaux, lesdits produits logiciels (P ; ) 
representant un premier niveau et comprenant, 
chacun, au moins un module (M^-M^) representant 
un deuxieme niveau, chaque module (M n -M Q ) 

40 comprenant au moins un jeu de fichiers (FS^ -FS^) 
representant un troisieme niveau, et chaque jeu de 
fichiers (FS^-FS^) comprenant au moins un fichier 
(F, 11 -F Q2 2) representant un quatrieme niveau, et en 
ce qu'un tichier determine n'appartient qu'a un seul 

45 jeu de fichiers, un jeu de fichier appartient a un seul 
module et un module appartient a un seul produit 
logiciel. 

16. Architecture selon la revendication 15, caracterisee 
so en ce que chacun desdits domaines (Dy) comprend 

au moins un module contenant un jeu de fichiers 
specifiques pour I'enregistrement dudit identifiant 
de domaine et desdites donnees sur les produits 
logiciels composant le domaine. 

55 

17. Architecture selon la revendication 15, caracterisee 
en ce que les jeux de fichiers associes aux produits 
logiciels dits externes contiennent des donn6es de- 
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crivant ces produits logiciels externes et permettant 
le controle de leur version lors de leur installation 
dans un domaine determine et/ou leur mise a jour 
dans ce domaine. 

5 

18. Architecture selon Tune quelconque des revendica- 
tions 15 a 17, caracterisee en ce que lesdits jeux 
de fichiers presents dans un domaine determine 
(D y ) sont disjoints. 

10 
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